This construct gives a compiler warning with gcc, saying that casting in an lvalue is deprecated.
Is this snippet equivalent?Code:if((DWORD)rtp & 1) ((char *)rtp)++;
Code:if((DWORD)rtp & 1) rtp = (char *)rtp + 1;
This construct gives a compiler warning with gcc, saying that casting in an lvalue is deprecated.
Is this snippet equivalent?Code:if((DWORD)rtp & 1) ((char *)rtp)++;
Code:if((DWORD)rtp & 1) rtp = (char *)rtp + 1;
What are you trying to do? This looks like an incredibly clumsy and dangerous punning effort.
My best code is written with the delete key.
Yes they are equivalent. But why are you casting anyway without an lvalue? Your variable is already a char * so no need to cast. Why not just do rtp++; and forget the cast. You would only want to cast into an lvalue to cast into the type of the variable to the left of the assignment or to prevent truncation in math expressions. I don't believe it makes sense to have a cast without an lvalue as the variable is already that type. For example if you had a float f and did something like this:
f = (float)123/(float)2;
Well, I guess context is a good thing... this is straight from the WINE source (or see here). I'm trying to figure out what it's trying to do, so I can fix it and avoid the warnings (and hopefully learn in the process):
If I'm not mistaken, rtp is a pointer to a riff_tag_t object, and then is getting changed to a DWORD for some bitwise hacking, then into a pointer to a char to increment.Code:static void handle_ani_list(riff_tag_t *lst, enum res_e type, int isswapped) { riff_tag_t *rtp = lst+1; /* Skip the "LIST" tag */ while((char *)rtp < (char *)lst + lst->size + sizeof(*lst)) { if(!memcmp(rtp->tag, info, sizeof(info))) { rtp = (riff_tag_t *)(((char *)rtp) + 4); } else if(!memcmp(rtp->tag, inam, sizeof(inam))) { /* Ignore the icon/cursor name; its a string */ rtp = NEXT_TAG(rtp); } else if(!memcmp(rtp->tag, iart, sizeof(iart))) { /* Ignore the author's name; its a string */ rtp = NEXT_TAG(rtp); } else if(!memcmp(rtp->tag, fram, sizeof(fram))) { /* This should be followed by "icon"s, but we * simply ignore this because it is pure * non-information. */ rtp = (riff_tag_t *)(((char *)rtp) + 4); } else if(!memcmp(rtp->tag, icon, sizeof(icon))) { handle_ani_icon(rtp, type, isswapped); rtp = NEXT_TAG(rtp); } else internal_error(__FILE__, __LINE__, "Unknown tag \"%c%c%c%c\" in RIFF file", isprint(rtp->tag[0]) ? rtp->tag[0] : '.', isprint(rtp->tag[1]) ? rtp->tag[1] : '.', isprint(rtp->tag[2]) ? rtp->tag[2] : '.', isprint(rtp->tag[3]) ? rtp->tag[3] : '.'); /* FIXME: This relies in sizeof(DWORD) == sizeof(pointer_type) */ if((DWORD)rtp & 1) ((char *)rtp)++; } }
>rtp is a pointer to a riff_tag_t object, and then is getting changed to a DWORD for some bitwise hacking, then into a pointer to a char to increment.
Yep, that's about as bad as I was thinking it was...
[edit]
And yes, they're equivalent.
[/edit]
Last edited by Prelude; 06-13-2004 at 08:08 PM.
My best code is written with the delete key.
so bad coding is the reason why WINE is unstable for me
No, Windows is the reason Wine is unstable.
Quzah.
Hope is the first step on the road to disappointment.
It seems from these responses that something more fundamental can be done to fix this problem, rather than just change the syntax to get rid of the warning.
Any tips?
lol nice oneOriginally Posted by quzah
It seems like I would have to do this (change to pointer to char, add 1, change back to pointer to riff_tag_t):
since the original rtp is a pointer to a riff_tag_t. Or does that happen automatically?Code:rtp = (riff_tag_t *)(((char *)rtp) + 1);
No. The hilighted code doesn't modify anything, other than incrementing the pointer. It says:
Quzah.Code:if( thisvalue has thisbitpattern set ) increment the pointer
Hope is the first step on the road to disappointment.
Right, I understand that. My question is about the incrementing part. Is it
orCode:rtp = (char *)rtp + 1;
because rtp is of type 'riff_tag_t *' to begin withCode:rtp = (riff_tag_t *)((char *)rtp + 1);
It seems to change the pointer to point to a location one byte away from the previous location, it doesn't seem to be normal pointer incrementation.Originally Posted by quzah
The one who says it cannot be done should never interrupt the one who is doing it.
From 6.5.4.2Originally Posted by joeljkp
Looking up the forward referenceConversions that involve pointers, other than where permitted by the constraints of 6.5.16.1, shall be specified by means of an explicit cast.
In this case, the casting you suggested seems necessary.6.5.16.1 Simple assignment
Constraints
1 One of the following shall hold:
— the left operand has qualified or unqualified arithmetic type and the right has arithmetic type;
— the left operand has a qualified or unqualified version of a structure or union type compatible with the type of the right;
— both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;
— one operand is a pointer to an object or incomplete type and the other is a pointer to a qualified or unqualified version of void, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;
— the left operand is a pointer and the right is a null pointer constant; or
— the left operand has type _Bool and the right is a pointer.
The one who says it cannot be done should never interrupt the one who is doing it.
Interesting. From what is that quoted? The C99 spec?